Information resource dictionary system: an integration mechanism for product data exchange specification

NISTIR 88-3862

Information Resource
Dictionary System: An
Integration Mechanism
for Product Data
Exchange Specification

Howard Bloom, Cita Furlani, Mary Mitchell, Joan Tyler, and David Jefferson*

U.S. DEPARTMENT OF COMMERCE
National Institute of Standards and Technology
(Formerly National Bureau of Standards)

Center for Manufacturing Engineering

‘National Computer and Telecommunications Laboratory

Gaithersburg, MD 20899

October 1988

75 Years Stimulating America's Progress

inj-m*

,

NISTIR 88-3862

Information Resource
Dictionary System: An
Integration Mechanism
for Product Data
Exchange Specification

Howard Bloom, Cita Furlani, Mary Mitchell, Joan Tyler, and David Jefferson*

U.S. DEPARTMENT OF COMMERCE
National Institute of Standards and Technology
(Formerly National Bureau of Standards)

Center for Manufacturing Engineering

‘National Computer and Telecommunications Laboratory

Gaithersburg, MD 20899

October 1988

National Bureau of Standards became the
National Institute of Standards and Technology
on August 23, 1988, when the Omnibus Trade and
Competitiveness Act was signed. NIST retains
all NBS functions. Its new programs will encourage
improved use of technology by U.S. industry.

U.S. DEPARTMENT OF COMMERCE
C. William Verity, Secretary

NATIONAL INSTITUTE OF STANDARDS
AND TECHNOLOGY
Ernest Ambler, Director

Information Resource Dictionary System:
an Integration Mechanism for
Product Data Exchange Specification

INTRODUCTION

This paper discusses the need for a mechanism that allows
various views of product data to interface with various
techniques for managing product data. The Information Resource
Dictionary System (IRDS) [ANSI Standard X3. 138-1988] is proposed
as an integration and configuration management mechanism for the
Product Data Exchange Specification (PDES) .

BACKGROUND

The design of manufacturable products is an increasingly
complex process for industry. Advances in technology have
resulted in compartmentalized life-cycle product development
activities. This has led to the isolation of the product
designer from others participating in product development. Those
isolated from access to the designer are: (a) the sponsor who has
the need for the product, (b) the process planner who understands
how the product can be produced in the factory, (c) the
manufacturing manager who understands the operation and
performance of the shop floor equipment, (d) the quality
assurance inspector who understands how to measure the
functionality of the product, (e) the service engineer who is
responsible for repair and preventive maintenance of the product,
and (f) the reliability engineer who is responsible for tracking
the performance of the product over its lifetime.

At each stage of the life-cycle, important knowledge about
the product is acquired. Unfortunately, this information is
seldom available to staff working on other stages of product
development. Specifically, the designer may not understand the
impact of his design on the creation of a true ’world-class'
product — one built to minimum cost with highest quality and
greatest functionality, in the shortest time span. To integrate
the isolated activities of product development, more attention
needs to be paid to the information exchange that occurs during
the product life-cycle.

With sophisticated and ever evolving technologies, users of
product data are faced with the need to exchange information
across diverse and dissimilar systems. At the same time, these
users must maintain the various contexts within their organiza-
tion and functional responsibility. ~ The - integration' of systems
as well as the integration of information within this technologi-
cal heterogeneity is the "core" of the developing Product Data

1

Exchange Specification (PDES) . Recognition of the need to
organize the integration and exchange of this information has
resulted in a major effort within the PDES community to define an
architecture for this purpose.

TOPICAL MODELS

The PDES community has been seeking solutions to manage and
exchange information about products as opposed to the graphical
exchange of drawings of products. The IGES/PDES Organization,
the voluntary standards organization, has been developing the
product information descriptions (called conceptual models)
across a broad industrial base (e.g. mechanical, electrical,
etc.). These descriptions, some common to many industries and
some unique to particular industries, form a "core of
information" about products. As application activities are
defined, committees have been formed to formalize the necessary
information shared between product development activities. This
effort has resulted in conceptual models which provide the
framework for the product information to be exchanged.

When a consensus has been reached on an individual topical
model, the model is then voted out of committee as a draft
specification. The various models have then been considered for
integration, when they contain common information. The PDES
Integration Committee was formed to find the overlaps and
intersections between different applications. Identification of
the integration elements needed to connect individual application
models has resulted in a "core" model called the Integrated
Product Data Model (IPDM) . This model is used to describe how
the topical models can be merged into the complete PDES
conceptual model.

The urgency to produce a PDES standard that is useful to the
industrial community has forced the decision to define PDES as a
collection of versions. Each new version enhances the product
data definition available in the previous version. In addition,
each new version will expand the scope of PDES to incorporate
more life-cycle activities. As these versions are released, the
techniques for representing the conceptual models may vary
because of the new complexity and richness of the specified
information. In addition, only the later versions will specify
sufficient product data to allow database and knowledge base
implementations to be efficiently built.

A conceptual model contains the fundamental objects and
concepts managed by an enterprise. The conceptual model also
depicts the relationships among the fundamental data objects of
the enterprise. Fundamental data objects are combined to create
useful collections of data which are subsets of the conceptual
model, called external views. An "external view" consists of

2

user-specific data and the structural organization of that data.
The procedures for creating the collections are unique recipes or
instructions for manipulating the fundamental data. These
procedures require management in their own right. They are not
part of the conceptual model. The rules for deriving external
views are user-specific and unique to each application.

Since the conceptual model includes all the important facts
about an enterprise, it can be thought of as a detailed
"database" containing vital constructs which can be extracted and
viewed in various ways. Extracts can provide a mechanism to
validate the content and intent of the conceptual model.

Once the first sharable topical product models were
generated and integrated, the PDES group had to consider the
following technical issue. How could the product model be
represented in a totally unambiguous manner? The answer was to
represent the information using a database design technique
called "data modeling." The various PDES application
subcommittees then implemented the specific topical data model in
a variety of data modeling formats. This caused a problem at
integration, as different data modeling techniques were used by
different application subcommittees. As with all technologies,
there are a range of tools, each of which is best for solving
specific problems. Improved and extended data modeling
techniques, as well as the tools to implement them, will continue
to appear in the future. Because PDES will be an ever evolving
standard, it is appropriate to allow the different topical data
models to be defined using a variety of data modeling techniques.

To be able to tolerate and integrate multiple modeling
techniques, a mechanism is needed for transferring specific data
models between the competing data modeling techniques. An ideal
candidate for this mechanism is a "data dictionary system" that
can save the product data model in a neutral specification.
Using a data dictionary system as this mechanism, it is then
necessary to implement only one pair of translators for each data
modeling technique. This allows for the translation of one data
modeling representation into the neutral format, and the
translation of the neutral format back into another data model
representation. The data dictionary system also becomes an
effective and efficient configuration manager for the development
of the IPDM.

PRODUCT DATA MANAGEMENT

The IPDM, resulting from the integration of the merged
topical models, abstractly defines the way in which the product
data elements^ interrelate. -In addition, ^the - "physical level"
defines the way the actual product data is represented, organized
and stored (such as on a disk or in memory) . [Figure 1] The PDES

3

community is currently defining levels of implementation for
PDES . These levels define the "road map" for how product life-
cycle activities (e.g. design, process planning, etc.) will
interface to the PDES implementation.

This leads to the second major issue: the development of a
mechanism that can manage the enterprise data and data semantics
for use in PDES implementations. This information management
capability can be supported by a data dictionary system that has
adequate functionality. The data dictionary system must be able
to interact with a variety of data storage techniques, such as
relational databases, file systems, object oriented databases,
etc. The data dictionary system must be able to describe the
data structures (e.g. strings, numbers, dates, tables, geometric
entities) that exist in the product information representation
and be able to cross-reference the associations among these data
structures. This PDES information must then be accessible to the
life-cycle systems through a neutral language that may be depen-
dent on the level of implementation but should not be dependent
on the actual system implementation (i.e., the language of a
given relational database management system (DBMS) or file
management system) .

APPROACH

The storage and management of all the components of PDES
development information in one logical, standard, data dictionary
system is the cornerstone for automation and reusability in the
future. Such a data dictionary system is required to manage the
numerous PDES topical and application models, model integration,
the validation process and the necessary documentation.

The Information Resource Dictionary System (IRDS) standard
being developed by the American National Standards Institute
(ANSI) and the National Institute of Standards and Technology
(NIST) can meet this need. The IRDS can be used to identify and
control all of the "pieces" that make up PDES and to evaluate the
effect of needed changes that will occur as the PDES standard
emerges. With the use of the extensibility feature, the IRDS
provides a stable platform for development and maintenance even
when the underlying technology is changing. [Figure 2]

The IRDS can support system integration by merging develop-
ment and maintenance tools into one environment. PDES develop-
ment requires the use of data modeling tools, data dictionaries,
DBMS, and, eventually, knowledge base systems to support all its
functions. Commercial and public-domain products exist in all
these areas. They can be easily obtained, but not easily
interfaced. The IRDS* can provide the mechanism by **which these
tools can be interfaced and replaced as new technologies emerge.

4

The IRDS can support the 3 -schema architecture (i.e., the
external view of the user, the logical conceptual model, and the
physical or implementation view of the internal model) . [Figure
3] Another way to visualize the three-schema architecture is as
a 3-dimensional space, with the three axes representing use,
processing and universality. Each of the three schemas —
external, internal and conceptual — can be represented as a
point in this space. The major component of each of the schema
points projects on a different axis: external projects on the use
axis, internal projects on the processing axis, and conceptual
projects on the universality axis.

This architecture permits the relationships between levels
to be independently defined, permitting some changes to be made
to the specifications at one level without affecting the speci-
fications at the other levels. Major changes, such as expansion
of scope, discovery of additional relationships, etc., will
impact all levels. Therefore, it is important to know how each
level is with the other through cross-referencing relationships.
The IRDS is the only recognized information management standard
in this area.

The IRDS provides a basic Functional Schema which directly
supports much of the information that an organization needs to
keep about implemented software systems. For example, the
ability to describe the data elements that make up a record and
how records are organized into a file is part of the IRDS BAsic
Functional Schema. Further, the IRDS provides a general schema
extensibility mechanism for tailoring and adding types of
information resources that need to be managed within an
organization. Schema extensibility is provided since the IRDS
does not intend to describe all of the types of resources that
enterprises may need to manage with a data dictionary. What is
provided by the standard is a schema with a minimum set of
information resource types, to be used as an example, along with
building blocks for extending the schema to meet each
organization's needs. It is this extensibility feature which
makes the use of IRDS so attractive.

What are the major categories of product data information
resources that must be managed if the full potential of an
information resource dictionary is to be realized for PDES? PDES
information resources can be grouped into three categories:

1) implemented systems and data organizations,

2) conceptual models and business rules, and

3) data usage and external views of data.

If the data types provided by the IRDS Basic Functional
Schema are examined, most of -them fall within - the^fdr st category
of information resources. The IGES/PDES Organization has spent
almost all its effort defining the second category of resource

5

types. Major efforts are still needed in the third category to
define industry and activity specific views of PDES or applica-
tion protocols.

To be a more complete and effective tool for the PDES
community, the IRDS schema structures must be modeled with an
Information Resource Dictionary (IRD) to store and access the
conceptual IPDM. The schema of this IRD must be extended to
capture and document the meaning of the entities, relationships
and attributes which comprise the integrated conceptual model.

Once a neutral conceptual model is developed, the IRDS can
be used to effect change control over existing applications and
databases. Currently, IRDS provides facilities for recording,
storing, and processing descriptions of data. It can create and
store schemas for all types of data management systems. Thus,
application programs will not need to incorporate the schemas
into their code; programs can obtain the necessary information
from the IRDS, resulting in a true data-driven system. The PDES
dictionary can also serve as the access control point for all
current models. The activities described below provide direc-
tions to pursue to support specific PDES needs. We are not
attempting to address more general problems.

ACTIVITIES

1. Build a schema for a PDES Information Resource Dictionary,
using the IRDS schema extensibility feature to support the
storage and management of the diverse conceptual models built by
the PDES committees.

The extensibility feature of IRDS will be used to define a
set of information resource types, called metatypes, which
correspond to each of the fundamental constructs found within
the conceptual modeling techniques used by PDES. This new
schema definition will allow IRDS to support the storage and
retrieval of conceptual models. Automatic dictionary loading
and version-controlled updates must be added to the existing
IRDS prototype to support management of the conceptual
models .

2 . Extend the PDES Information Resource Dictionary schema to
support a full three-schema architecture, and populate the IRD
with PDES information.

Initially this repository will hold the conceptual models,
supporting entity definitions, and scoping statements, as
well as related, but unresolved, issues. The IRDS Basic
Functional Schema supports only information * describing the
internal schema, specifically physical databases and files,
computer hardware, and user profiles. Therefore, the PDES

6

IRD schema will be expanded to support a full three schema
dictionary. When application subsets, testing criteria, test
cases, and implementation guidelines are developed, the PDES
dictionary can then be populated with relevant information.
This will permit evaluation of the effects of changes and
expansions in the PDES standard. These resources can then be
brought into alignment with the standard.

3. Develop automated or assisted translation between diverse

data models and represent these data models in the IRDS .

There are three types of data models being produced by PDES
activities. PDES Version I will contain both EXPRESS and

IDEF1X, two types of data models. In addition, some

committees are formalizing their work in NIAM, a third type.
A NIAM model must be translated into both IDEF1X and EXPRESS
before it can be incorporated into the PDES standard.
Equivalent concepts between these models must therefore be
identified and formally represented to ensure that the

different types -are consistent. Translating these data

models into the IRDS can provide PDES with a unified

representation of this information, and permit consistency
checking among the data models.

4. Interface the PDES Information Resource Dictionary to

available software.

The IRDS provides for integration between data modeling
tools, database and system design aids, and application
development. As the repository for dictionary metadata
describing functions, data, and objects that compose an

application, the IRDS becomes the key integration tool for
PDES application development. In addition, it provides the
IRDS Export/Import Facility to control moving IRD schema and
metadata definitions from one site to another. The IRDS
Export/Import Facility is currently under development at
NIST.

4.1 Utilize conceptual modeling tools.

These tools are used in the requirements analysis and system
design phases. They provide quality controls in the
definition of both data models and functional design. Most
will also generate a prototype database schema in one or more
relational data definition languages. Most also have an
interchange form. This interchange form is the most likely
method for interfacing these tools to the IRDS. No
standardization efforts are active within ANSI to develop a
standard conceptual modeling language that could be used for
this purpose.

7

4.2 Support IRDS information interchange with DBMS.

DBMS provide a general purpose capability for storing,
accessing, and managing actual instances of data. The
Structured Query Language (SQL) standard and the Network
Database Language (NDL) standard are expected to be the first
of the DBMS related standards to be interfaced to the IRDS
standard. Remote Data Access (RDA) , an International
Organization for Standardization (ISO) standards effort, is
not yet mature enough for an interface to IRDS to be
designed. RDA also supports less capability than a
distributed PDES database implementation needs. However, ISO
has done enough work in the distributed area to identify the
minimum information requirements that a data dictionary/di-
rectory must manage to support this distributed aspect. The
IRDS Service Interface, which is currently under review, is
an addendum to the IRDS standard that will support the use of
the IRDS in an active mode. The Services Interface is
expected to be formally accepted as part of the IRDS standard
in 1990-91.

5. Develop Relationships to Physical Design.

The PDES organization is not heavily concerned with how PDES
is physically implemented because many of these issues fall
under the domain of implementors. There are aspects of
physical design, however, that must be managed to maintain
consistent versions of PDES; PDES will produce an exchange
format and testing suites which must conform to the
conceptual models defined in the standard. Therefore the
elements of the conceptual models must be associated with
those of the exchange format and testing libraries. Further,
there must be an ability to document the decisions made in
the physical design of these modules and to detect changes
required to keep these modules consistent with newer versions
of PDES. These types of cross-referencing information can be
captured and stored in the IRDS.

8

GLOSSARY

Application Model

A data model which addresses the information requirements
for a specific industry or vital - business - objective such as
electrical design or structural analysis.

Conceptual Model

An abstraction of the real world that conveys the concepts,
meaning and semantics of information for an organization. It
forms the basis for a dialogue between systems and users and is
based on a common understanding of the information it represents.

Data Attributes

Properties of product data which describe the data objects.
Data Dictionary

A repository for data definitions, system documentation,
data representations, and requirements descriptions of
information managed within the automated or manual systems of an
organization. This resource is then available over the life-
cycle of developing and existing systems.

Enterprise

May be a corporation, a unit or division of a corporation,
government unit, or group of cooperating organizations, etc.,
which is the source or owner of information.

External View

That set of information which is sufficient to support the
performance of a particular function or business objective.

Fundamental Constructs

Defines the basic constructs used to create the data model.
Each data model technique will have a set of primitive elements
that are used to formally describe an actual data model.

Heterogeneity

Use of dissimilar computer hardware and software in support
of a common objective.

9

Implementation Model

A design of the data organization for a system. For database
systems this would be a database schema in the definition
language of the database management system selected to implement
the system. For- applications, this would be * the data structures
in the computer language used to write the application and for
object oriented systems, this would be the object class
definitions .

Integration

The process of merging together independently developed
models into a cohesive and consistent model which reflects a
common understanding of information resources used within an
enterprise.

IRD Data Layer

The layer of the information resource dictionary that
manages the actual descriptions of information resources.

IRD-IRD Interface Facility

A method of exchanging information resource dictionaries to
additional sites which may have processing responsibilities.

IRD Schema Description Layer

Provides the basic framework on which to build the types of
information resources to be managed within an information
resource dictionary.

IRD Schema Layer

Defines the types of information resources to be managed
within an information resource dictionary; these are called
metatypes .

IRDS

The Information Resource Dictionary Standard is a draft
proposed ANSI and FIPS data dictionary standard.

Knowledge Base

A system which is capable of persistent data management and
can actively enforce the business rules defined against the data.
A knowledge base is capable of evaluating requested functions and
performing constraint checking on the data. - — • ■ i

10

Level I Implementation

A passive file interchange implementation of PDES.

Level II Implementation

An active file interchange implementation of PDES.

Level III Implementation

A database implementation of PDES.

Level IV Implementation

A knowledge base implementation of PDES.

Life-Cycle

The distinct phases into which every system may be divided
such as requirements, design, implementation, production, and
maintenance. Each phase may require different support from the
data dictionary which is used to administrate it.

NDL

The Network Database Language is the ANSI standard for data
definition and access for network databases.

Physical Design

The process of evaluating an implementation model or design
and factoring in performance characteristics and data access to
optimize the design.

PDES

Product Data Exchange Specification is a developing standard
which will provide for the unambiguous interchange of life cycle
product data from concept, to engineering design, to manufacture,
and to support.

RDA

The Remote Data Access protocol is an ISO standards activity
which is developing a standard for distributed system access.

SQL

The Structured Query Language is the ANSI standard data
definition and access for relational databases.

11

Topical Model

A data model which incorporates the requirements of many
users into a data model of limited scope. The scope defines the
topic of the data model (e.g. geometry data model) .

12

c n

o

Figure

co J2
O <y

II

U)

o

mmm

o >

CD O ~

s: >* o
-i o <

c

a>

E

o fl>

"D co SH

Son
Q. Q S

ENTERPRISE STRUCTURE

0-0
u w u

eu < cu

NBS-T14A (rev. 2-bo

U.S. DEPT. OF COMM.

U.S. DEPT. OF COMM.

BIBLIOGRAPHIC DATA

SHEET (See instructions)

1. PUBLICATION OR

88-3862

2. Performing Organ. Report No.

3. Publication Date

OCTOBER 1988

4. TITLE AND SUBTITLE “ “

Information Resource Dictionary System Applications (IRDS) : An Integration

Mechanism for Product Data Exchange Specification (PDES)

5. author(S) Howard Bloom, Cita Furlani, Mary Mitchell, Joan Tyl

er, David Jefferson

6. PERFORMING ORGANIZATION (If joint or other than NBS, see in struction s)

NATIONAL BUREAU OF STANDARDS
U.S. DEPARTMENT OF COMMERCE
GAITHERSBURG, MD 20899

7. Contract/Grant No.

8. Type of Report & Period Covered

9. SPONSORING ORGANIZATION NAME AND COMPLETE ADDRESS (Street. City. State, ZIP)

10. SUPPLEMENTARY NOTES

| | Document describes a computer program; SF-185, FlPS Software Summary, is attached.

11. ABSTRACT (A 200-word or less factual summary of most significant information. If document includes a significant
bibliography or literature survey, mention it here)

With sophisticated and ever evolving technologies, users are faced with the need to
exchange information across diverse and dissimilar systems. At the same time the users
must maintain the various contexts within their organization and functional responsi-
bility. The integration of systems as well as the integration of information within
this technological heterogeneity is the "core" of product data exchange specification.
The need to organize the integration and exchange of this information has been
recognized.

A way to store and manage all the components of PDES development in one logical, stand-
ard, dictionary system is the cornerstone for automation and reusability in the future.
The complexity of the integration task, the validation process, the numerous topical
and application models, and the necessary documentation, require the use of a dictionary
tool to manage and track the model integration stage of the PDES life cycle. The
Information Resource Dictionary System (IRDS) standard being developed by ANSI and NEST
can> meet this need. The IRDS can be used to identify and control all of the "pieces"
that make up PDES and to evaluate the effect of needed changes that will occur as the
PDES standard emerges.

12. KEY WORDS (Six to twelve entries; alphabetical order ; capitalize only proper names; and separate key words by semicolons )

CAD, Computer Integrated Manufacturing, conceptual models. Data Dictionary,
data modeling, factory automation, IRDS, PDES, product data, product data exchange

13. AVAILABILITY

14. NO. OF

PRINTED PAGES

(_Xl Unlimited

f" 1 For Official Distribution. Do Not Release to NTIS

1 Order From Superintendent of Documents, U.S. Government Printing Office, Washington, D.C.
20402.

15. Price

FX! Order From National Technical Information Service (NTIS), Springfield, VA.

22161

$9.95

USCOMM-DC 6043-P80